The Unlicensed Mobile Access (UMA) specifications recommend security mechanisms for the interfaces between the mobile station (MS) and access point (AP), the MS and unlicensed network controller (UNC), the MS and CS part of the core network (i.e., mobile services switching center (MSC)/visiting location register (VLR)), and the MS and application servers. The Up-interface between the MS and the UNC is secured using IPsec “tunnel mode”. In essence, each Internet Protocol (IP) packet sent by the UNC is encrypted by the UNC-SGW and then put into another IP packet. The initial IP packet header is called the “inner” header (and is encrypted) and the generated new IP packet header is called the “outer” header (and is not encrypted). The UMA specifications also recommend that the AP is “transparent” to traffic between the MS and UNC. This means that the AP is not addressed in the application level and the traffic signaling is between the MS and the UNC. As a result, standard, off-the-shelf APs can be used for UMA.
This is also the case in the 3d Generation Partnership Project (3GPP) standards for “Generic Access to A and Gb-interface”, otherwise known as a Generic Access Network (GAN). See 3GPP Technical Specifications 43.318 (Stage-2) and 44.318 (Stage 3). Note that the generic access network controller (GANC) in the 3GPP specifications is equivalent to the UNC in the UMA specifications. Similarly, the generic access network controller secure gateway (GANC-SEGW) in the 3GPP specifications is equivalent to the UNC-SGW in the UMA specifications.
These standard APs are not managed and do not have any quality-of-service (QoS) mechanisms to make sure that the end-user experience is good enough when calls are being made over the UMA network. This means that the AP cannot differentiate between different types of traffic (e.g., signaling, voice and GPRS data). Yet the AP is one of the critical points in delivering the needed QoS from the AP to the MS (downlink direction) and the MS to the AP (uplink direction).
The problem lies in the fact that all traffic going through the AP between the MS and the UNC or GANC is encrypted and the only thing visible in the AP is the “outer” IP header. This means that it is impossible to base any prioritization of the packets at the AP on transmission control protocol (TCP) or user datagram protocol (UDP) port numbers, packet types, etc. because all this information is encrypted. The only information that the AP can use to differentiate between different traffic types is contained in the outer IP header, outer UDP header, encapsulated security payload (ESP) header and ESP Auth. Although, the UNC or GANC could mark the DiffServ/TC/ToS bits in the outer IP header and the AP could prioritize different types of traffic based on this information, there is no guarantee that this information will be unmodified when the packets arrive at the AP. The DiffServ, Traffic Class (TC) and Type of Service (ToS) fields are described in The Internet Engineering Task Force publications RFC 2474, RFC 2460 and RFC 791, respectively. Moreover, service providers are not required to use the same node mechanisms or configurations to implement QoS differentiation, so an AP may not recognize or properly decode the DiffServ/TC/ToS bits in the outer IP header. As a result, there is no good way for an AP to prioritize traffic belonging to different traffic types. Accordingly, there is a need for a method and apparatus for prioritizing encrypted traffic at an intermediate node within a communications network.